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Abstract — This paper proposes a simple and stateless active 
queue management (AQM) scheme, called geometric CHOKe 
(gCHOKe), to protect responsive flows from unresponsive ones. 
The proposed gCHOKe has its root on and is a generalization 

I of the original CHOKe. It provides an extended power of flow 
protection, achieved by introducing an extra flow matching trial 
upon each successful matching of packets. Compared to the plain 
CHOKe, analysis and simulation show that gCHOKe can achieve 

I over 20% improvement in the bounds of both bandwidth and 
buffer space used by an aggressive flow. In addition, up to 14% 
of the total link capacity can be saved from the unresponsive flow, 
allowing responsive or rate-adaptive flows to obtain a better share 

] of resources in the router. 

; Index Terms— AQM, RED, CHOKe, TCP, Flow Protection 

I 1. Introduction 

A classical way to enforce fairness in the Internet has been 
with the help of congestion avoidance algorithms implemented 
at the end hosts. Such end-to-end (e2e) schemes, however, 

[ provide no incentives for users, and an unresponsive end host 
or flow, which (intentionally or unintentionally) lacks e2e 

' congestion avoidance scheme, may end up with a lion share of 
bandwidth in the network. Therefore, they should be comple- 
mented with router mechanisms that can help enforce fairness 
by identifying unresponsive flows and restricting their share of 
bandwidth. Generally speaking, there are two types of router 
schemes for this purpose: (1) per flow scheduling schemes 
(e.g., SFQ Q]) and, (2) active queue management schemes 
(e.g., RED 121). The former type schemes are usually stateful 
and require the router to identify flows and to dynamically 
manage possibly huge number of queues. These requirements 
impose complexity and scalability issues in implementation. 
An active queue management (AQM) scheme normally only 
has and operates on one queue, and is more scalable and easier 
to implement. 

Among the existing AQM schemes, RED (Random Early 
Detection) ||2l is perhaps the most widely known. RED is a 
stateless scheme. A congested RED router randomly drops 
incoming packets with a certain probability. Since packets are 
admitted to or dropped by the RED queue probabilistically, 
both the packet drop and admission histories form an unbiased 
statistics about the state of affairs regarding the rate of active 
flows. As a result, a flow is more likely to have packet drop 
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or admission tallies proportional to its rate of arrival. This 
implies that even with RED, an unresponsive flow can still 
get high bandwidth share and starve responsive flows. To deal 
with this problem, several RED variations have been proposed, 
such as FRED (Flow Random Early Drop) fS) and RED- 
PD (RED with Preferential Dropping) lH. These schemes 
leverage the recent flow history to identify and control high 
bandwidth flows. Particularly, these schemes keep state for 
the high-bandwidth (and possibly unresponsive) flows with 
which additional controlling of their throughput is enforced. 
However, while appealing, these schemes become stateful or 
need to maintain and make use of partial flow state ||4|. 

In Is), an original and highly novel scheme, called CHOKe, 
is proposed to protect responsive flows from unresponsive 
ones. It can easily be implemented by a simple tweaking of 
the RED algorithm. CHOKe is completely stateless with no 
need of storing or maintaining flow level state at the router. 
It uses the recent admissions, i.e. packets currently queued in 
the buffer, to penalize the high bandwidth flows. Specifically, 
"when a packet arrives at a congested router, CHOKe draws 
a packet at random from the FIFO buffer and compares it with 
the arriving packet. If they both belong to the same flow, then 
they are both dropped; else the randomly chosen packet is left 
intact and the arriving packet is admitted into the buffer with 
a probability that depends on the level of congestion." 

In addition to its simplicity and stateless implementation, 
another desirable property of CHOKe is that it ensures 
bounded bandwidth and buffer shares |]6| Q. Specifically, 
unresponsive flows in CHOKe cannot exceed a certain band- 
width share or buffer limit in the presence of many responsive 
flows. The following theorems 161 provide an overview of this 
property, where UDP represents the extreme of unresponsive 
traffic: 

Theorem 1. 1) The maximum UDP bandwidth share in 
CHOKe is bounded by (e+ 1)"' = 26.9%. 

2) This is attained when UDP input rate, after congestion 
based dropping, is C(2e - l)/(e+ 1) = 1.193C, where C 
is the link capacity, and 

3) In that case, CHOKe-based UDP dropping rate is 
(e-l)/(2e-l) = 38.7%. 

Theorem 2. When UDP input rate increases without bound, 
its buffer share approaches 50% but its Unk utilization ap- 
proaches 0. 



Given these nice properties of CHOKe, it is natural to ask 
if CHOKe can be generalized and/or if the performance can 
be improved. Trying to give answers to these questions forms 
the motivation of this work. Particularly, we aim to generalize 
CHOKe, while retaining its desirable qualities, i.e., simplicity 
and statelessness, and simultaneously empower it with tighter 
control on or some tuning knob to control the use of link 
bandwidth and buffer space. 

In this paper, we introduce geometric CHOKe (gCHOKe), 
which turns out to be a highly intuitive scheme based on the 
design principle of CHOKe. A analytical model that charac- 
terizes the throughput and buffer occupancy an unresponsive 
flow can maximally receive under gCHOKe is also presented. 
The analysis, which is validated through extensive simulation, 
shows that gCHOKe can achieve over 20% improvement in 
the bounds of both bandwidth and buffer space used by the 
aggressive flow. In addition, up to 14% of the total link 
capacity can be saved from the unresponsive flow, allowing 
responsive or rate-adaptive flows to obtain a better share 
of resources in the router These results provide additional 
insights into CHOKe. 

The rest of this paper is structured as follows. Section |2] 
outlines the main idea behind gCHOKe. gCHOKe model 
and assumptions for the analysis are presented in Section [3] 
Section|4]presents theoretical analysis of UDP throughput and 
packet loss rates. In Section |5] the model is validated and 
additional results are given. Section |6] concludes the paper. 

2. Geometric CHOKe (gCHOKe) 
A. The Scheme 

When a packet arrives to a congested queue, gCHOKe 
randomly samples a packet from the queue. If the incoming 
and the sampled packet belong to the same flow, gCHOKe 
continues to sample another random packet from the queue. 
Matching process stops upon a failed matching trial, or when a 
pre-defined maximum number of trials is reached. All matched 
packets and the arriving packet are dropped. In the event of 
no matching at first attempt, the sampled packet is restored to 
the queue, but the arriving packet may still be dropped with 
a probability that depends on the level of congestion. In the 
case that the buffer is managed by RED, this probability is 
determined by the RED parameter settings. Throughout this 
paper, we call such congestion-based dropping probability the 
ambient drop rate or the RED loss rate. 

The alert reader may have noticed that, by setting the pre- 
defined maximum number of trials to 1, gCHOKe reduces to 
CHOKe. Recall that, the main idea and design principle behind 
CHOKe is that a high-bandwidth unresponsive flow will likely 
have more packets in the buffer, hence a higher probability 
of matching and consequently dropping. Due to this, CHOKe 
punishes the unresponsive flow from possibly dominating the 
use of the buffer and the link. 

The above design principle of CHOKe is inherited by 
gCHOKe. However, gCHOKe additionally rewards each suc- 
cessful matching with a bonus trial. The succession of bonus 
trials provides an extra shield of protection to rate-adaptive 
flows from unresponsive ones. By choosing / tuning the 



defined maximum number of trials, a desired protection level 
may be achieved. This introduces flexibility for traffic control, 
which is lacking in the original plain CHOKe. 

For ease of presentation and due to space Umitation, in the 
rest of the paper, we do not limit the predefined maximum 
number of matching trials per arrival. In other words, the 
number is infinity. This is an extreme case. Any number 
between 1 and infinity gives a performance between that of 
the plain CHOKe and this extreme gCHOKe. Similar analysis 
applies, and the results are omitted. 

B. Example Scenario 

We compare gCHOKe against CHOKe and RED using 
simulation of the network setup shown in Fig. [2] where there 
are N ^ 32 TCP flows. The full simulation parameters are 
given in Section 15-AI The result (Fig. [1) shows that RED 
has no fairness mechanism in place. UDP share exceeds 90% 
of link capacity and this starves out the TCP flows. Under 
CHOKe, UDP is restricted to 26% of link capacity. Using 
the enhanced flow protection afforded by gCHOKe, UDP 
throughput is restricted further down to 19% — a saving of a 
modest 7% of link capacity C, or an overall improvement of 
27% over CHOKe. The improvement can be much higher with 
higher rate UDP flows (see Fig. iTab . 
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Fig. 1. gCHOKe can restrict high bandwidth flows better than 
CHOKe and RED. 



3. The Model 

This section lays out the model and theoretical foundation 
for the study of steady state performance of gCHOKe. 

A. The System and Assumptions 

The studied system is shown in Fig.|2] The link capacity is C 
(pkts/sec) and the buffer is of size b (pkts). We study behavior 
in the steady state which we assume exists. There is a single 
unresponsive / aggressive UDP flow and rate-adaptive simi- 
lar TCP flows. For analytic simplicity, we consider a gCHOKe 
queue where the ambient and gCHOKe based droppings are 
reversed (see also Fig. |4] ). We highlight that similar model 
and assumptions have been used for CHOKe analysis ||6| Q. 

B. Notation 

Notations are shown in Table |T] Flows are indexed by i, 
where ; € {0,N). Index denotes the UDP flow, and indices 
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Fig. 2. System model. 



I...N denote TCP flows. To avoid confusion, a hat over a 
parameter, e.g., p, is often used to refer to a parameter in the 
CHOKe scheme. 

TABLE I 

Notation of steady state parameters. 



Parameters 



b, 
Pi 
hi 
t 
b 



Semantics 



source rate of flow i 
flow i packets in buffer 

total flow ;■ drop or loss rate (both RED and gCHOKe) 

the ratio bjb (matching probability) 

the steady-state queueing delay for TCP flows 

total backlog b = YJiLo ^i in packets 

congestion or RED-based dropping probability, or 

ambient drop probability (common to all flows) 



C. The Analytical Foundation 

The analysis is based on deriving the overall loss / admission 
probabilities in the steady state for an arbitrary flow. 

Consider a flow / whose packet reaches the gCHOKe queue. 
Since the first dropping is due to RED, by assumption, the 
packet is dropped with probability r or is admitted by RED 
with probability 1 — r. After admission by RED, a random 
packet is sampled from the queue for matching. The flow 
matching probability is = bi/b. If the packets match, the 
arriving packet earns a bonus to continue further matching by 
drawing another packet. This continues until a no-match (or a 
pre-defined maximum number) is encountered. Assuming that 
hi does not change much in the same matching experiment, 
this results in a sequence of conditional Bernoulli trials. The 
probability of exactly ^ e [li---) matches is given by /!^(1— /i,) 
and this results in loss of ^ + 1 packets from flow /, which are 
the k matched packets plus the arriving packet. Assuming large 
b, the total loss probability is, 

°° ih—lP- 
p,- = r + ^ ( 1 - r) + 1 ( 1 - hi) = r + ( 1 - r)^—^. 

(1) 



A second way to derive the overall drop probability is as 
follows. Consider an arbitrary packet of flow /. This packet 
survives both dropping and gets queued to the tail with 
probability (1 — r)(l — hi). This packet may still be dropped 
when future packets of the same flow trigger potentially 
multiple matchings. How many comparisons or samplings can 
be tried per each incoming packet? In other words, how many 
matching trials can be performed before a mismatch happens. 
If n comparisons are executed, the first « — 1 of them must be 



matching and the last one is the mismatch that aborts the pro- 
cess. This happens with probability h"^^{l — hi). The number 
of trials is thus a Geometric random variable with parameter 
qi=l— hi. The expected number of trials per arriving packet is 
then l/qi= 1/(1 —/i,). Since a steady state queuing delay T is 
assumed, an average of — r)T flow ; packets arrive during 
T. A total of TXi{l — r)/{l — hi) flow matchings can be tried 
before the enqueued packet gets transmitted. The probability 
of a trial failing to match the enqueued packet is (l — l/b). 
Therefore, the overall probability with which a packet survives 
all droppings is given by the product, 

TXi{l-r)/(l-hi) 



l-p, = {l-r){l-hi)[l-^- 



(2) 



4. UDP Throughput Analysis 

Using the gCHOKe model developed in the last section, 
we are interested in how much bandwidth UDP can "steal" in 
the presence of many TCP sources. In the analysis, the only 
independent parameter is the incoming rate xq of UDP. 

We assume that the gCHOKe link is fully utilized, i.e.. 



xo{l-pQ)+Nxi{l-pi)=C. 



For large A^, 



hi = — = ^ — sa 0. 

b bo+Nbi N 



Using (|4|i in ([T]i, we get for a TCP flow 



Pi 



(3) 



(4) 



(5) 



Eqs. (HI and (|5]l imply that TCP packets seldom trigger 
matching and are mostly dropped due to ambient dropping. 

The approximations (HI and ^ together with ^ are used 
to derive t. The number of TCP packets in the buffer is 
A^^i = b — bo = b{l — ho), and the aggregate TCP rate is given 
by Nx\{l — pi). By virtue of Little's Law, we get 

A^^i _ b{l-ho) 



Nxi{l-pi) C-xo{l-po) 
From (|6]l and (|2|i, we find for flow 0, 

''-'-o(i-'-) 

/ 1 \ < 

1 



(6) 



PQ -■ 



1 \ c-.vn(i-pn) 



For large b, the approximation (1 — 1 /b)'' w e ' can be used 
to simplify the above equation to, 

1 - po = (1 - '■)(1 - ho)e c--^o(i-po) (7) 

From ([Til, 

l-po = l-(r+il-r)^-^]={l-r) 



I -he 



I -ho 



(8) 



For a packet to be finally transmitted, it must escape both 
the ambient dropping and successive matching trials from 
incoming packets. The term {I — r) in ^ corresponds to 
the probability of surviving the ambient (RED) loss, while 
the second term {h^ — 3ho + !)/{! — ho) is the probability 



of escaping gCHOKe based packet loss. Therefore, the pure 
gCHOKe based packet loss from a flow with buffer share Iiq 
is given by (see also dTJ): 



PgCHOKe 



1 



3/10+1 _ 2/io-/Jo 



(9) 



1 - /iO 1 - llQ 

For CHOKe, the corresponding drop rate can be shown ||6| , 

Pchoke^2ho. (10) 

Remark: Pi,cHOKe is a convex function of Iiq, and hence, at 
higher buffer shares, assumes higher drop rates than Pchoke- 
Equating ([8]) and (|7]) for flow and simplifying, we obtain 

= exp| 



hl-3hQ+l 



- exp 



A-o(l-r) 
C-xo(l -po) 
xo(l-r)/C 



(11) 



1 -xo(l -po)/C" 
Define the UDP utilization jiQ, 

Ho^xo{l-po)/C. (12) 

This also means that xq/C = Aio/(l ^ Po)- Replacing 1~ po 



by (1-r) 



/!6_JAo+i^ from (O, we simplify ( fTTT i to: 



/i^ - 3/io + 1 
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/i^- 3/70+1' 



(13) 



(14) 



Substituting ( fT4l i in ( fT3] l and rearranging (fT3T l. /io becomes 
ln[(l-/to)y(/To)] 
r(/zo)+ln[(l-/zo)r(/^o)] ^ 
a graphical view of which is shown in Fig. [3] 

The next two theorems summarize the above analysis. 

Theorem 3. The maximum UDP link utilization is 
Mo"' 



: 20.5%, which is achieved when ho w 29%. 



Proof: Eq. ( fTSl ) has a local maximum within the allowed 
/lo range, see also Fig. [3] By setting djio/dliQ =0, we get the 
maximum numerically at Iiq w 0.29, and 



ln[(l-/tg)y(/zS)] 
yih*) + ln[{l-h*)yih*)] 



; 0.205. 



Theorem 4. The UDP buffer share in gCHOKe is upper- 
bounded as ho (3 - \/5)/2 w 38.2%. 

Proof: The proof follows from (|9]l and the fact that 

PgCHOKe 



2hQ - 



" ^ 1 . Solving 2/10 — /!q ^ 1 — ho gives 



(l-/!0) 

/jo ^ ^^2*^ or /i ^ ^^2'^ . The first is invalid since cannot 
be greater than 1. The proof follows from the second. ■ 
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Fig. 3. Eq. M5\ in graphical form. 



From Ths. 3 and 4, it is easy to see that large UDP buffer 
occupation does not generally yield high UDP utilization in 
gCHOKe due to the leaky nature of the queue. This property 
is a sharp contrast to FIFO. In addition, as Iiq increases from 
0.29 to /i™^ = (3 - v^)/2 w 0.382 where the maximum UDP 
buffer share is reached, PgCHOKe rapidly increases to 1 and 
the UDP utilization steadily drops from the maximum possible 
jUq = 0.205 to near zero. 

Combining ([T2]i and (O, we find the ratio of UDP 
traffic admitted by gCHOKe: 



Mo 



hi - 3ho - 



1 



1 



xo(l-r)/C 1-/70 r(M' ^^^^ 

That means, out of xo(l — r) UDP rate that passes the ambi- 
ent drop, jUoC are transmitted by gCHOKe and xo(l — r) — jiqC 
are dropped by gCHOKe. The rate of gCHOKe based dropping 
is then. 



xo{l -r)-iioC 
xo(l -r) 



= 1 - 



= 1 - 



xo{l -r) 
1 



r(/^o) 



2/io - hi 
l-/in 



— PgCHOKe- (17) 



It follows that 1 /7(/!o) and PgCHOKe are gCHOKe's admission 
and dropping rates respectively. 

A summary of the theoretical results for the gCHOKe model 
is shown in Table The table is useful for understanding the 
relationships between the various parameters of the model. 
Many of them are self-explanatory and can be obtained from 
the formulae above. The "I/0(input/output)" in the last but one 
row refers to the relation between the input UDP traffic after 
ambient dropping, i.e., xo(l — r) and the UDP utilization or 
transmission rate /Xo, which follows readily from ( fT6] l. 

Before concluding this section, we remark that the reversal 
of RED and gCHOKe based droppings has small impact on 
overall drop probability pQ. If we followed the actual gCHOKe 
depicted in Fig. HI instead of ([T]i, we would have obtained. 



PQ = PgCHOKe + r{l- ho) 



2ho - hi 



+ r{l-ho) (18) 



1-/70 

The difference between ( fTSl l and ([T]) is r{pgCHOKe — ho) 
which is insignificant, largely due to small r. Compared to 
that in RED, r in gCHOKe is generally smaller. The reason is 
that since gCHOKe drops excessively in response to increasing 
input xq, the average queue length avg is less in gCHOKe. 
This in turn keeps r smaller and makes the po approximation 
in ([T]i reasonably accurate. 



TABLE II 

Summary of theoretical results in steady state. 



Parameter 


gCHOKe Model Formulation 


Intermediate variable 




\\j IXC uiup udie 


PgCHOKe i i/7l«0j 


UDP utilization 


\n[(l-ho)Y(ho)l 
^" riho) + ln\il-ho)r(ho)] 


UDP I/O relation 


xo{l - r) / C = ^oyiho) 


UDP admission rates 

(1-po) 


^l-r)[l- PgCHOKe) = {^-r)lY{hQ) 
= {1- r){l-ho){l - LY-'o(l-r)Rl-ho) 
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Fig. 4. Actual gCHOKe scheme. 



5. Model Validation and Simulation Results 

A. Simulation Environment and Default Settings 

We have implemented gCHOKe and all simulations are 
performed in ns2-34. Unless otherwise stated, the following 
simulation parameter^ are used: The bottleneck link has a 
capacity of C = IMbps, a latency of 1ms and a buffer capacity 
b = 300A:Z?. RED buffer thresholds are set as min,/, = 20 and 
max,/, = 300. We use = 32 TCP-SACK flows and all packets 
are 1000 bytes. Flow start times are random and uniformly 
distributed on [0,10]. All simulations are replicated 20 times 
and each runs for 200s, but only the results of the last 100s 
are taken. The 95% confidence intervals are very small and 
hence are not reported. 

B. Model Validation 

As explained before, the only independent parameter of the 
model is the input UDP traffic rate xq. In Fig. |5] we plot 
theoretical UDP utilizations and buffer shares as we vary the 
input UDP rate xo{l - r) from O.IC to IOC. It is trivial to 
generate these (indeed all) theoretical plots from parameter 
interdependencies summarized in Table As can be seen 
from simulation results in Fig. |6] the model is very accurate. 

C. Results and Discussion 

From the theoretical and matching simulation results, we 
highlight the following salient points: 

. UDP utilization bounds: CHOKe (26.9%) and gCHOKe 
(20.5%); UDP buffer share bounds: CHOKe (50%) and 
gCHOKe (38.2%). Both gCHOKe bounds are tighter by 
over 20% over CHOKe's. 

• For low and moderate UDP traffic rate, there is no 
significant difference between CHOKe and gCHOKe in 
terms of UDP utilization or buffer share levels. 

'a parallel set of experiments with C = 20Mbps, b = 1MB, min,;, = 20, 
max,;, = 1000, N = 100 gives statistically consistent results. 
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Increasing UDP input rate initially increases the buffer 
share, but does not allow buffer monopoly (see Fig. l5bb . 
UDP's buffer shares eventually stabilize around their 
peaks (see also Fig. [3]). 
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• In sharp contrast to Drop Tail and RED (e.g., see Fig.[T]i, 
while indefinitely increasing UDP input traffic will in- 
crease the corresponding buffer share, it may not yield 
higher utilization for UDP in both CHOKe an gCHOKe 
(see Fig. |5ali. Particularly, increasing the input rate be- 
yond 0.682C backfires in gCHOKe since each incoming 
UDP packet potentially triggers a sequence of successful 
comparisons at soaring rate. UDP utilization peaks at 
20.5% in gCHOKe {vs. 26.9% in CHOKe). This occurs 
when 29% of the packets in buffer are UDP (vs. 39% 
for CHOKe). This means, as UDP buffer ratio increases 
from 29% to 38.2% due to increased input, PgCHOKe 1 
and UDP utilization drops off from maximum 20.5% to 
almost 0. 

• The high UDP buffer occupancy but low UDP utilization 
(see Fig. |5a] and Fig. l5b] i at high incoming UDP rate 
implies nonuniform UDP packet distribution in the queue 
where most of the UDP packets may have been clustered 
closer to the tail of the queue. 

In view of the last property, it is easy to see that packets 
enter the queue tail at a rate [xo(l — ho) +Nx\ (1 — /ii )] (1 — r), 
but exit only at the rate of C. When xq is high, since /ii w 
(see Eq. |4|i and r is realistically insignificant, most of the 
UDP packets get dropped as they advance towards the head 
of the queue. Assuming a fluid model, we say the UDP 
flow is thinned by flow matching. The power of thinning 
is intrinsic to the scheme and is unique to a flow rate xq. 
The flow controlling or thinning power of the schemes is 
conveniently captured by Eq. (|2]i. An arriving UDP packet 
gets enqueued at queue tail with probability {1 — r){l — ho). 
The UDP flow gets thinned due to flow matching by factors of 
{l-l/b)''^o(i-r) and {1 -llb)''''o('-r)l{i-ho)^ respectively for 

CHOKe and gCHOKe, before the flow packet can reach the 
head of the queue. When /iq is excessively high, due to high 
input UDP traffic rate xq, the thinning exponent of gCHOKe 
increases faster. In the extreme case when /j'q'" = 0.382, 
each arriving UDP packet in gCHOKe performs, on average, 
l/{l~h'U"-') « 7.62 matching trials. This allows gCHOKe to 
restrict the UDP bandwidth and buffer shares to lower levels. 

Fig. Ililpresents the difference between the UDP utilization 
levels that can go under CHOKe and gCHOKe. Note that 
while it is difficult to derive An = lichoke{xo) - l^-gCHOKeixo) 
for a given xq in closed form, UDP utilization values can be 
computed numerically (also from Fig. |5a]i for a given input 
rate xq. The resulting AjXo is plotted in percentage of C for 
selected input rates in Fig. [Ta] As can be seen, gCHOKe 
wields better control of high bandwidth flows. Up to 14% of 
the total link bandwidth can be saved by using gCHOKe! As 
a consequence, gCHOKe provides better throughput to TCP 
flows, as shown by Fig. |7b] The simulation results generally 
fit the theoretical TCP throughput (see Eq. |3]l except for some 
dips especially at higher input UDP rates. We believe that this 
is due to approximation errors in TCP dropping probabilities, 
see Eq. |5] As TCP gains more throughput, the incidence of 
successful TCP flow matching increases. This in turn results 
in occasional packet losses and drops in TCP bandwidths. 
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Fig. 7. More bandwidth is available for TCP Flows under gCHOKe. 

6. Conclusion 

Regardless of the outcome of the experiment, CHOKe maxi- 
mally triggers a single trial of flow matching per packet arrival. 
Therefore, flow protection in CHOKe is flat. In this paper, we 
present gCHOKe, a generalization of CHOKe, which provides 
additional power of protection and at the same time retains 
the statelessness and simplicity of CHOKe. gCHOKe rewards 
a successful flow matching with a bonus trial. Depending 
on the recent admission history of the flow, or the ratio of 
flow packets queued in the buffer, a single packet arrival may 
trigger a succession of packet droppings. With this way, a flow 
with relatively many recent arrivals can be controlled further, 
leaving the network resources (buffer and link bandwidth) to 
responsive flows. Compared to CHOKe, the flow protection 
performance of gCHOKe is superior ensuring tighter upper 
bounds in the use of network resources by a UDP flow. 
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